<?xml version="1.0" encoding="utf-8"?>
<!--
                                                                                     
 h       t     t                ::       /     /                     t             / 
 h       t     t                ::      //    //                     t            // 
 h     ttttt ttttt ppppp sssss         //    //  y   y       sssss ttttt         //  
 hhhh    t     t   p   p s            //    //   y   y       s       t          //   
 h  hh   t     t   ppppp sssss       //    //    yyyyy       sssss   t         //    
 h   h   t     t   p         s  ::   /     /         y  ..       s   t    ..   /     
 h   h   t     t   p     sssss  ::   /     /     yyyyy  ..   sssss   t    ..   /     
                                                                                     
	<https://y.st./>
	Copyright © 2016 Alex Yst <mailto:copyright@y.st>

	This program is free software: you can redistribute it and/or modify
	it under the terms of the GNU General Public License as published by
	the Free Software Foundation, either version 3 of the License, or
	(at your option) any later version.

	This program is distributed in the hope that it will be useful,
	but WITHOUT ANY WARRANTY; without even the implied warranty of
	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
	GNU General Public License for more details.

	You should have received a copy of the GNU General Public License
	along with this program. If not, see <https://www.gnu.org./licenses/>.
-->
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<base href="https://y.st./en/weblog/2016/03-March/13.xhtml" />
		<title>Webkit isn&apos;t the problem &lt;https://y.st./en/weblog/2016/03-March/13.xhtml&gt;</title>
		<link rel="icon" type="image/png" href="/link/CC_BY-SA_4.0/y.st./icon.png" />
		<link rel="stylesheet" type="text/css" href="/link/basic.css" />
		<link rel="stylesheet" type="text/css" href="/link/site-specific.css" />
		<script type="text/javascript" src="/script/javascript.js" />
		<meta name="viewport" content="width=device-width" />
	</head>
	<body>
		<nav>
			<p>
				<a href="/en/">Home</a> |
				<a href="/en/a/about.xhtml">About</a> |
				<a href="/en/a/contact.xhtml">Contact</a> |
				<a href="/a/canary.txt">Canary</a> |
				<a href="/en/URI_research/"><abbr title="Uniform Resource Identifier">URI</abbr> research</a> |
				<a href="/en/opinion/">Opinions</a> |
				<a href="/en/coursework/">Coursework</a> |
				<a href="/en/law/">Law</a> |
				<a href="/en/a/links.xhtml">Links</a> |
				<a href="/en/weblog/2016/03-March/13.xhtml.asc">{this page}.asc</a>
			</p>
			<hr/>
			<p>
				Weblog index:
				<a href="/en/weblog/"><abbr title="American Standard Code for Information Interchange">ASCII</abbr> calendars</a> |
				<a href="/en/weblog/index_ol_ascending.xhtml">Ascending list</a> |
				<a href="/en/weblog/index_ol_descending.xhtml">Descending list</a>
			</p>
			<hr/>
			<p>
				Jump to entry:
				<a href="/en/weblog/2015/03-March/07.xhtml">&lt;&lt;First</a>
				<a rel="prev" href="/en/weblog/2016/03-March/12.xhtml">&lt;Previous</a>
				<a rel="next" href="/en/weblog/2016/03-March/14.xhtml">Next&gt;</a>
				<a href="/en/weblog/latest.xhtml">Latest&gt;&gt;</a>
			</p>
			<hr/>
		</nav>
		<header>
			<h1>Webkit isn&apos;t the problem</h1>
			<p>Day 00372: Sunday, 2016 March 13</p>
		</header>
<p>
	I checked in on the <a href="https://codereview.qt-project.org/#/c/152150/">Qt pull request</a> and found that it has been merged! If <a href="apt:arora">Arora</a> doesn&apos;t have it&apos;s own <abbr title="Server Name Indication">SNI</abbr> bug, Arora is now fixed.
	Additionally, the <a href="https://bugzilla.gnome.org/show_bug.cgi?id=763510"><abbr title="GNU Network Object Model Environment">GNOME</abbr> bug report</a> has been changed again, this time to reflect that the bug is in glib and that it relates to networking in an unspecified version.
	People are actually looking at it and passing it to the developers of the particular subproject so that it can actually get fixed.
	This is better than I dared hope for! With a little luck, maybe the <a href="https://bugs.webkit.org/show_bug.cgi?id=155378">Webkit bug</a> will be taken seriously as well.
	However, while I was out, I saw that the Webkit people are saying that the &quot;host name/<abbr title="Server Name Indication">SNI</abbr> mismatch&quot; error thrown by the server is caused by the fact that Webkit is sending the correct <abbr title="Hypertext Transfer Protocol">HTTP</abbr> Host header and correct <abbr title="Server Name Indication">SNI</abbr> host name, and because one has a trailing dot and the other does not, they don&apos;t match.
	As I&apos;ve tested what happens when you send the correct <abbr title="Server Name Indication">SNI</abbr> host name and correct <abbr title="Hypertext Transfer Protocol">HTTP</abbr> Host header, I knew that this isn&apos;t the case.
	I was under the impression that the &quot;mismatch&quot; was that the two didn&apos;t correspond with one another because the trailing dot <abbr title="Server Name Indication">SNI</abbr> host name doesn&apos;t correspond with <strong>*any*</strong> <abbr title="Hypertext Transfer Protocol">HTTP</abbr> Host header, as it&apos;s invalid.
	I thought that I&apos;d have to set up my own <abbr title="Hypertext Transfer Protocol">HTTP</abbr> server that the Webkit people could access, which would be a breach of my <abbr title="Internet service provider">ISP</abbr>&apos;s terms of service.
	With my own Web server, I might be able to nudge my server into providing access to my Web application by using a couple lines of code in a <abbr title="PHP: Hypertext Preprocessor">PHP</abbr>-based 400 error page.
	After running into a strange error in Iceweasel that prevented me from loading the <abbr title="Server Name Indication">SNI</abbr> testing page (Iceweasel refused to allow me to accept the &quot;invalid&quot; certificate), I tried a subdomain of the main testing page because the certificate specifically mentioned being valid for two subdomains.
	Much to my surprise, I found that not only did the new page not set off Iceweasel&apos;s anti-<abbr title="Transport Layer Security">TLS</abbr> error, it also didn&apos;t set of the server&apos;s error, despite the fact that the Web browser was still sending a malformed <abbr title="Server Name Indication">SNI</abbr> host name.
	Using this to my advantage, I was able to show the show the Webkit people the malformed <abbr title="Server Name Indication">SNI</abbr> host name sant by Web browsers using their software.
	By the end of the night, they did understand the problem.
	However, they say that the bug isn&apos;t in Webkit, but somewhere else.
	The person I spoke with confirmed that the error is in Safari (which I couldn&apos;t test myself), Chrome (Which I assumed had the error because <a href="apt:chromium">Chromium</a> does), and <a href="apt:iceweasel">Firefox</a> (which I already reported the bug in).
	He said he&apos;d pass the information on to Apple so that they can fix Safari, which should lead to one more Web browser being fixed.
	However, it means that I still need to figure out who to report the problem in <a href="apt:surf">Surf</a> to.
</p>
<p>
	Speaking of playing games with the 400 error page, I found that I can display an actual page on my choosing in place of the default 400 error page, though doing so is less intuitive than I&apos;d like.
	It might be possible to write a tricky 400 error page that checks to see if the cause of the error is a malformed <abbr title="Server Name Indication">SNI</abbr> host name, and if it is, return the page that would have otherwise been returned if the <abbr title="Server Name Indication">SNI</abbr> host name wans&apos;t present or was correct.
	I might use this for a Web-based game if I have time to build it.
	People that are running reasonable Web browsers might get a bonus while those running unreasonable Web browsers might get an inverse bonus and be presented with a link to an explanation.
	The explanation would provide links to the bug reports on known Web browsers and invite the user to either pressure the developers into fixing them, file their own bug report against an unlisted Web browser, or switch to a known-working Web browser.
</p>
<p>
	I spent most of the day in Springfield, trying to remove a broken faucet to replace it with one that might work.
	However, most likely due to heavy corrosion, I wans&apos;t able to fully remove it.
	I&apos;m not sure what we&apos;re going to have to do about it.
</p>
<p>
	On the way home, I was thinking about moss and wondering if it&apos;s harmful to the trees it grows on.
	I thought that I recalled hearing that moss doesn&apos;t sap the nutrients out of trees, but the roots of the moss digging into the tree had to be doing damage.
	And if the moss is digging into the tree, why doesn&apos;t the tree&apos;s immune system fight off the moss? I looked it up on the way back, and it turns out that <a href="http://1800cuttree.com/content/moss-bad-trees">moss isn&apos;t in fact harmful to most trees</a> and isn&apos;t a parasite.
	While moss does produce threadlike structures that help it hold onto the tree, it has no roots and doesn&apos;t actually dig into the tree.
	This probably explains why moss can grow so well on stones too.
	The biggest threat that moss poses to trees seems to be its weight.
	If a particularly weakened and/or old tree has too much damp moss on it, it might not be able to support it all and that could lead to breaking.
</p>
		<hr/>
		<p>
			Copyright © 2016 Alex Yst;
			You may modify and/or redistribute this document under the terms of the <a rel="license" href="/license/gpl-3.0-standalone.xhtml"><abbr title="GNU&apos;s Not Unix">GNU</abbr> <abbr title="General Public License version Three or later">GPLv3+</abbr></a>.
			If for some reason you would prefer to modify and/or distribute this document under other free copyleft terms, please ask me via email.
			My address is in the source comments near the top of this document.
			This license also applies to embedded content such as images.
			For more information on that, see <a href="/en/a/licensing.xhtml">licensing</a>.
		</p>
		<p>
			<abbr title="World Wide Web Consortium">W3C</abbr> standards are important.
			This document conforms to the <a href="https://validator.w3.org./nu/?doc=https%3A%2F%2Fy.st.%2Fen%2Fweblog%2F2016%2F03-March%2F13.xhtml"><abbr title="Extensible Hypertext Markup Language">XHTML</abbr> 5.1</a> specification and uses style sheets that conform to the <a href="http://jigsaw.w3.org./css-validator/validator?uri=https%3A%2F%2Fy.st.%2Fen%2Fweblog%2F2016%2F03-March%2F13.xhtml"><abbr title="Cascading Style Sheets">CSS</abbr>3</a> specification.
		</p>
	</body>
</html>

